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Introduction 

Health  Information  Technology  (HIT)  systems  should  facilitate  the  collection  and  point-of-care 
access  to  accurate,  comprehensive,  contextually  rich  clinical  data  for  all  acuity  levels  of 
healthcare.  Open  platforms  of  plug-and-play  medical  devices  and  clinical  information  systems 
could  enable  improved  quality  and  timeliness  of  data,  as  well  as  cost-effective  development  of 
innovative  third-party  medical  “apps”  for  diagnosis,  treatment,  research,  safety  and  quality 
improvements,  equipment  management,  and  adverse  event  detection  and  reporting. 

The  Medical  Device  “Plug-and-Play”  (MD  PnP)  Interoperability  program  was  established  in  2004 
to  lead  the  development  and  adoption  of  open  standards  and  related  technologies  in  order  to 
achieve  this  vision.  The  MD  PnP  program  is  affiliated  with  Massachusetts  General  Hospital 
(MGH),  CIMIT  (Consortia  for  Improving  Medicine  with  Innovation  &  Technology),  and  Partners 
Healthcare  System,  with  additional  support  from  TATRC  (U.S.  Army  Telemedicine  &  Advanced 
Technology  Research  Center).  The  clinically  grounded  MD  PnP  program  has  taken  a  multi¬ 
faceted  approach  to  address  key  barriers  to  achieving  interoperability,  including  the 
development  and  support  of  suitable  open  standards  (e.g.  ASTM  F2761-09(13),  Integrated 
Clinical  Environment,  or  “ICE”);  the  elicitation,  collection  and  modeling  of  clinical  use  cases  and 
system  engineering  requirements  for  an  open  architecture  instantiation  of  ICE  as  a  platform  and 
“ecosystem”;  alignment  of  clinical  organizational,  manufacturer,  and  FDA  regulatory 
expectations;  and  implementation  of  prototype  use  cases  in  an  open  “sandbox”  or  testbed 
environment. 

The  MD  PnP  program  has  built  a  geographically  dispersed,  interdisciplinary,  multi-institutional 
team  to  develop  and  implement  a  strategy  to  address  historical  barriers  and  accelerate  the 
achievement  of  device  interoperability  through  collaboration.  Since  the  program’s  inception, 
more  than  900  clinical  and  engineering  experts,  and  representatives  of  more  than  140 
companies  and  institutions  have  participated  in  our  plenary  workshops  /  conferences,  working 
group  meetings,  and  focus  groups  to  contribute  to  ongoing  program  activities  that  helped  shape 
the  common  goals.  Our  team  of  collaborators  has  included  participants  from  healthcare  delivery 
organizations  (e.g.  Kaiser  Permanente,  Johns  Hopkins  Medicine,  the  VA),  federal  agencies 
(including  the  FDA,  NIST,  TATRC,  and  NSF  Cyber  Physical  Systems),  university  computer  and 
information  science  groups  (e.g.  Pennsylvania,  Illinois/Urbana-Champaign,  Kansas  State), 
device  manufacturers  (e.g.  Draeger  Medical  Systems,  Philips  Healthcare,  GE  Healthcare,  small 
companies  (e.g.  DocBox,  Moberg  Research,  Anakena  Solutions,  large  companies  (e.g.  Intel, 
MITRE,  Lockheed  Martin),  and  the  Partners  Healthcare  System  community  (MGH  Anesthesia, 
Critical  Care,  and  Pain  Management,  Biomedical  Engineering  at  MGH  and  Brigham  &  Women’s 
Hospital,  and  Partners  Healthcare  Information  Systems). 

TATRC  support  for  MD  PnP  program  development  has  enabled  significant  progress  towards  the 
goal  of  achieving  medical  device  interoperability.  TATRC’s  funding  has  leveraged  additional 
synergistic  project-specific  funding  from  CIMIT,  NSF,  NIST,  and  NIH,  but  it  is  TATRC  funding 
that  has  uniquely  made  possible  our  program’s  enabling  efforts  that  are  moving  medical  device 
interoperability  and  patient  safety  forward  along  parallel  pathways  of  requirements,  standards, 
platform  development,  and  regulatory  approach.  A  major  outcome  of  TATRC  funding  has  been 
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enabling  our  team  to  form  and  grow  a  diverse  community  of  involved  and  committed 
collaborators  and  stakeholders.  A  pertinent  example  of  our  ability  to  coalesce  interest  and 
commitment  around  an  important  issue  is  the  support  from  the  White  House  and  standards 
bodies  for  accurate  medical  device  clock  time. 

Body  of  Report 

The  goal  of  the  Medical  Device  “Plug-and-Play”  (MD  PnP)  Interoperability  program  is  to 
accelerate  medical  device  interoperability  to  enable  the  creation  of  complete  and  accurate 
electronic  health  records  and  the  cost-effective  development  of  innovative  third-party  medical 
“apps”  for  treatment,  research,  safety  and  quality  improvements,  equipment  management,  and 
adverse  event  detection  and  reporting  when  using  networked  medical  devices  for  clinical  care. 
TATRC  support  for  MD  PnP  program  development  has  enabled  significant  progress  towards  the 
goal  of  achieving  medical  device  interoperability.  This  award  reflects  new  and  emerging 
technologies  and  research,  and  builds  on  prior  and  current  MD  PnP  program  work  (awards 
#W81XWH-06- 1-0651  and  W81XWH-09-1-0705),  to  develop  tools,  applications,  and  sharable 
databases  to  advance  the  state  of  the  art  of  medical  device  interoperability  and  enable  a 
broader  community  of  developers  to  implement  medical  device  interoperability. 

For  Option-Year  1  of  this  award  (scheduled  to  end  30  November  2014),  we  proposed  the 
following  aims: 

Aim  1 :  ICE  Data  Logger 

Develop  a  software  research  prototype  of  the  Data  Logger  component  conforming  to  the  ICE 
standard  (ASTM  F2761).  Data  logging  is  necessary  to  address  regulatory  and  liability  concerns 
regarding  networked  medical  device  systems,  and  will  improve  the  forensic  analysis  of  clinical 
adverse  events  and  near  misses. 

•  Implement  NIST  research  prototype  Data  Logger  on  MD  PnP  open  platform 

•  Improve  playback  to  support  adverse  event  analysis  (work  with  FDA  and  ECRI  Institute) 

•  Add  support  for  narrative  texts  (e.g.  clinician  interviews)  and  placement  of  events  on  a 
timeline 

•  Continue  experiments  with  Unique  Device  Identifiers  in  collaboration  with  the  FDA 

Aim  2:  Web-Based  Clinical  Scenario  Repository 

Develop  a  sharable  repository  of  clinical  scenarios  that  could  be  improved  through  better 
medical  device  and  health  IT  integration.  The  scenario  repository  will  provide  use  cases  to 
inform  design  of  the  Data  Logger,  and  can  eventually  be  used  by  researchers,  standards 
developers,  regulators,  and  manufacturers  to  create  innovative  solutions  for  many  intractable 
clinical  problems. 

•  Release  beta  version  of  Clinical  Scenario  Repository  to  collaborators  for  testing  and 
feedback 

•  Gather  scenarios  and  feedback  from  collaborator  users  about  the  site  design  and  data 
collected 

•  Improve  the  site  to  incorporate  and  reflect  feedback 

•  Implement  a  full  public  site  launch,  including  promoting  it  to  the  Patient  Safety  and 
Clinical  Engineering  communities 

Aim  3:  Open  Source  Code  Dissemination,  or  ICE  Apps  Exchange  (ICE  AX) 

Disseminate  open-source  code  developed  by  the  MD  PnP  program  and  collaborators,  including 
the  prototype  Data  Logger,  in  order  to  facilitate  further  development  by  others. 
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•  Release  any  NIH/QMDI  app  deliverables  into  ICE  AX  repository 

•  Present  work  at  open  source  conference  or  meeting,  and  recruit  volunteers  to  contribute 

•  Develop  new  reference  implementation  apps  or  app  frameworks,  and  release  to  ICE  AX 
repository 

Aim  4:  ICE  External  Interface  Data  Transfer 

Define  and  document  external  interfaces  to  bi-directionally  transfer  medical  device  and  patient 
contextual  data  between  the  integrated  clinical  environment  and  external  systems  of  national 
interest.  Demonstrate  the  interface  to/from  one  or  more  of  these  systems  (depending  on  which 
are  ready  and  accessible): 

•  Explore  feasibility  of  connecting  MD  PnP  Lab  to  MGH  test  ADT 
(Admission/Discharge/Transfer),  POE  (Physician  Order  Entry),  and  pharmacy  systems 

•  Prototype  connection  to  hospital  external  interfaces,  starting  with  ADT 

•  Use  NwHIN  connectivity  in  demo  scenario,  e.g.  allergy  list  in  drug  administration 

Research  Accomplishments 

Data  Logger,  Aim  1 :  Develop  a  software  research  prototype  of  the  Data  Logger  component 
conforming  to  the  ICE  standard  (ASTM  F2761). 

Our  Data  Logger  project  has  greatly  benefited  from  our  ongoing  collaboration  with  a  research 
group  at  NIST  using  their  own  internal  funding.  Starting  with  documentation,  requirements,  and 
guidance  from  our  team,  NIST  surveyed  relevant  data  logger  work  in  avionics,  automotive,  and 
other  domains  to  identify  additional  requirements.  NIST  compiled  this  set  of  data  logger 
requirements  and  produced  a  technical  white  paper  about  the  different  levels  or  modes  of 
logging  that  an  ICE  Data  Logger  will  need  to  support.  We  plan  to  write  a  paper,  in  collaboration 
with  both  NIST  and  FDA,  based  on  this  work  that  will  compare  our  ICE  Data  Logger  to  data 
loggers  in  other  domains,  in  order  to  highlight  the  specific  needs  that  differentiate  clinical  data 
logging  from  aerospace  or  automotive  data  logging. 

This  detailed  comparison  with  other  data  loggers,  such  as  aircraft  flight  data  recorders  and 
automotive  loggers,  has  enabled  us  to  work  with  NIST  to  leverage  their  unique  engineering 
expertise  to  build  a  consensus  set  of  requirements  to  feed  back  to  the  NIH-funded  QMDI  project 
and  the  broader  community,  and  to  use  for  development  of  an  ICE  Data  Logger  standard.  We 
have  been  documenting  the  range  of  existing  data  logging  strategies  to  serve  as  design  inputs 
for  our  Data  Logger  and  to  serve  as  an  informational  resource  for  the  community. 

Beginning  in  November  we  focused  much  of  our  Data  Logger  effort  on  preparing  a  draft 
standard  for  the  ICE  Data  Logger:  Medical  devices  and  medical  systems  —  Basic  safety  and 
essential  performance  of  the  patient-centric  integrated  clinical  network  environment  (ICE): 
Particular  requirements  for  the  forensic  data  logger.  We  decided  that  taking  time  to  write  the 
draft  standard  would  be  valuable  in  identifying  further  requirements  before  the  next  round  of 
development. 

As  part  of  the  drafting  of  this  standard,  we  reviewed  literature  and  standards  associated  with 
data  loggers  covering  different  modes  of  transportation,  publications  describing  clinical  data 
loggers,  and  earlier  work  on  requirements  done  by  the  MD  PnP  Program  to  highlight  the  specific 
needs  of  clinical  data  logging.  In  addition,  FDA  guidance  and  other  documents  (e.g.  event 
codes,  unique  device  identification  guidance,  medical  device  reporting  regulations)  and  other 
ISO  standards  (e.g.  clinical  evaluations)  were  consulted  and  cited  to  ensure  consistency  of  the 
requirements  in  the  draft  standard  with  these  documents. 
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Work  continues  on  a  companion  supporting  paper  tentatively  titled  “The  Case  for  Routine  Use  of 
and  Standardization  of  Forensic  Clinical  Data  Loggers”,  a  version  of  which  is  intended  for 
publication  in  a  journal  with  a  medical  technology  readership,  and  on  a  concept  of  operations 
document  for  the  ICE  Data  Logger  standard.  In  order  to  provide  additional  supporting  rationale 
for  the  draft  standard,  we  are  exploring  the  modification  and  inclusion  of  requirements  related  to 
patient  privacy  and  data  security.  Our  continuing  participation  in  related  standards  activities  - 
including  ISO  TC  121,  IEEE  11073  POC/PHD,  and  the  Joint  AAMI/UL  2800  -  will  help  ensure 
harmonization  with  other  standards  work. 

In  May  Dr.  Goldman  and  consultant  Michael  Jaffe  presented  the  draft  Data  Logger  standard  to 
the  team  at  NIST  for  feedback  that  we  have  since  incorporated  into  the  draft.  In  preparation  for 
sharing  this  draft  standard  with  a  broader  group  of  domain  experts,  we  have  circulated  the  draft 
to  additional  selected  collaborators  for  review.  Much  of  their  initial  feedback  has  been 
incorporated,  and  we  plan  to  distribute  the  updated  draft  to  a  larger  group  of  experts  for 
comment.  The  draft  Data  Logger  standard  needs  further  iterations  to  enhance  its  suitability  for 
submission  into  the  standards  development  process  as  a  new  work  item  proposal  (NWIP).  In 
view  of  expanding  awareness  of  the  importance  that  ICE  data  logging  could  play  in  emerging 
complex  HIT  environments,  we  are  considering  whether  to  hold  a  workshop  on  clinical  data 
logging  to  obtain  broader  community  involvement. 

We  worked  closely  with  NIST  on  their  implementation  of  an  initial  research  data  logger 
prototype  -  implementing  many  of  the  identified  requirements,  and  intended  to  demonstrate 
some  of  the  challenges  and  our  approach  to  logging  and  playback  for  ICE  -  on  their  in-house 
developed  Data  Flow  System.  This  prototype  was  demonstrated  as  part  of  a  set  of  MD  PnP  and 
collaborator  demonstrations  held  at  NIH  on  August  21-22  2013,  attended  by  more  than  65 
representatives  from  TATRC  and  federal  agencies  including  FDA,  NIST,  NSF,  NIH,  ONC,  and 
others. 


Figure  1:  The  ICE 
Data  Logger  & 
Playback 
Demonstration 
Architecture 


Transport  Middleware 
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Feedback  from  the  audience  at  the  August  demonstrations  made  it  clear  that  there  is 
considerable  and  widespread  interest  in  this  work. 

For  the  next  Data  Logger  implementation,  we  built  preliminary  data  logging  functionality  on  the 
OMG  DDS  (standards-based)  middleware  we  are  using  for  our  OpenICE  platform  development, 
using  our  ICE  Equipment  Interfaces.  We  are  successfully  logging  data,  as  illustrated  in  the 
screen  shots  in  Figures  2  and  3.  Figure  2  shows  an  application  that  displays  data  on  the 
network  in  real  time.  This  application  can  also  be  used  to  record  the  data  to  a  file.  Figure  3 
shows  the  logged  data  for  a  waveform.  These  applications  are  engineering  prototypes  intended 
for  application  development  and  debugging.  Figure  4  shows  a  capture  from  our  current 
engineering  prototype,  containing  samples  of  data  from  several  devices.  This  log  includes  the 
unique  device  identifier  as  well  as  synchronized  timestamps  and  device  data  in  a  standardized 
nomenclature.  We  are  still  using  our  proposed  UDI  format,  since  FDA  guidance  on  UDI  is 
focused  on  device  labeling,  barcodes,  and  RFID. 
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ckOIRiiDOpJt21FuLliRzHUNbJnl<>eblACce8 
jgREBYpT9q  lSMvdV9nvt8rjU6n4FhERrJINV 
s|gTVdaNtNtKXCp3ZoyHeVqhr9bAythBB7« 
r  kfllRhDOpJf?  I  Fill  I  YRyHONhJnlder.lArreR 
s  jqTVrl.iNtNtKXCp37oY  >  k*Vqhr9hAyThRR7e 
|y  RFRYpT9i|  1  5MvilV9nvl  R  r  |l  l6n  4FliFRr|l  N  V 
s  i»TV>I..NlN  I  KXr*i«7><v1  kAhilir  QKAi/l  l>RR7.- 


metricjd  value 

MDC  PRESS  BLD  NONINV  MEAN  92.0 
MIX.  RtbP  RAIL  0.0 

MDC_PUL5_0XIM_5Ar_02  100.0 

MfX"_CO?_AC7TVF_AI  ARMS  0.0 

MDC_Pll  L5_0XIM_SAT_02  88.0 

MDOAWAYC  07FXP  7f,.0 

MDC_FA5T_5TAT11S  1)0 

MDC  PRFSS  CIIFF  IXA  *4.0 

MDC  PRESS  CUF  F  SYS  121.0 

MDC  PRESS  BLD  SYS  120.0 

MDC_PRLSS_BLD_MtAN  95.0 

MDC_Pll  LS_RATE_NON  _INV  69.0 

MDC_Ptl  L5_OXIM_PtlL5_RATE  CC.O 

MOC_FCG_CARD_RFAT_RATF  *0.0 

MDC<U  OW5TATUS  197.0 

MOC_FCG_CARD_RFAT_RATF  70.0 

Mnc  cpt>7  Ar  tivf  ai  aruv  n  o 


unkjee_d«vtee_  identifier 
ckOIRI.DOpJf2  lFuLl  3RzHONbJnki«6IACce8 
ckO  IRIiDOpjf  2  IF  uL  1  IRzHON  b]  r  1 1d  eb  lACte  8 
CkO  IRhDOpjf  2  IF  U  L 1 JRZHON  DJn  Id  eb  lACce  8 
,lg  REB  Y  pT9q  IS  MvdV  9  n  vt  8  rllj  6  n4  F  h  F  Rr  IjNV 
ckOIRhDOpJf21FuL13RzHONbJnlde6lACce8 
rkOIRhDOpJf?  1  Fiji  1  3R7HONhJnldef.lArreR 
JqRFRYpT9ql5MvrfV9nvtftrJllf,n4FhFRrJINV 
H|RFRYpT9i|lSMvilV9nvtRrjllF>n4FhFRrjlNV 
IVdaNlNlKXCplZuv  lleVqhr  9bAylhBB7e 
R)RtBYpT  9q  15  MvdV9nvl8r  JUbn4F  FitRiJINV 
Jg  RtBY  P  T  9q  15  MvdV  9nvt8rJUbn4F  bEKrJINV 


metrkjd 

MDC  CAPNOCRAPH 
MDC  PULS  OXIM  I’LL  I H 
MDC_PRL55_BLD 
MDCJHII  S.OXIM.Pl  FTW 
M  DC_ECG_AM  PL_ST_I 
MF>C_PRF55JII  D 
Mf)C_FCC._AMP1  _5T_III 
MDC  PRF5S  Rl  D  ART  ARP 
MDC  CAPNOCRAPH 
MDC  LCO_AMPL_5T_ll 
MDC_ECC_AMFT_5I_I 


values 

IO.O.O.O.O.O.O.O.O.O.O.O.O.O.C 

(337.0,33  7.0.337.0.337.0,33 

( 195.0. 19  7.0.199.0.200.0 .20 

l?B46.0,?774.0,?64S,0,?fiU 

(241.0.242.0,242.0.242.0.24 

(507.0,507.0,507.0,507.0,50 

(ft  193  0,A193  0.A193  0.R193 

(7165  0.7161  0.7156  0.715 1 

115.0.13.0.12.0.11.0.11.0 

18187.0.8187.0.8187.0.8187 

18185.0.8185.0.8185.0.8185 


Figure  2:  Data  Logging  Application 
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Logged  Data  [ice::SampleArrayJ 


eoo 


Timestamp 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 

20140212 


10:22:28.059 

10:22:29.083 

10:22:29.083 

10:22:29.083 

10:22:29.083 

10:22:30.107 

10:22:30.107 

10:22:30.107 

10:22:30.107 

10:22:31.131 

10:22:31.131 

10:22:31.131 

10:22:31.131 

10:22:32.155 

10:22:32.155 

10:22:32.155 

10:22:32.155 

10:22:33.179 

10:22:33.179 

10:22:33.179 

10:22:33.179 

10:22:34.203 

10:22:34.203 

10:22:34.203 

10:22:34.203 

10:22:35.227 

10:22:35.227 

10:22:35.227 

10:22:35.227 

10:22:36.251 

10:22:36.251 

10:22:36.251 

10:22:37.275 

10:22:37.275 


values 

11024.0,1022.0,1023. 0,1028.0.1033.0,1040.0, 1047.0,1053. 0.1058.0,1062. 0.1065.0, 1069.0.1074.C 
[1416.0,1509.0,1635.0.1795.0, 1983.0,2187.0, 2392.0,2581.0, 2743.0,2869.0.2957.0I3011.0,3037.( 
[1718.0, 1662.0, 1615.0,1579.0, 1554.0,1540.0, 1537.0,1544.0, 1558.0, 1576.0, 1595.0, 1613.0.1627.C 
[1140.0, 1123.0,1108.0,1093.0, 1081.0,1071.0,1063.0, 1056.0,1049.0, 1043. 0.1037.0.1032.0.1028.C 
[1140.0, 1152.0,1165. 0,1178.0, 1189.0, 1201.0, 1215.0,1233.0, 1257.0,1289.0,1333.0, 1395.0.1482.C 
[2629.0,2544.0.2455.0,2366.0, 2278.0,2192.0, 2108.0,2026.0, 1947.0,1873. 0,1802.0, 1737.0, 1681. ( 
[1462. 0,1425.0, 1392.0, 1361.0, 1332.0, 1303.0, 1275.0, 1247.0, 1220.0, 1194. 0,1170.0, 1149.0, 1132.C 
[1062. 0,1067.0,1072.0, 1077.0, 1081.0,1084.0, 1087.0, 1092. 0,1099.0,1109.0,1120.0, 1131.0, 1145.C 
[2888.0, 2968.0,3014.0, 3033.0, 3030.0, 3008.0, 2973.0, 2928.0, 2873.0,2810.0, 2739.0, 2661.0, 2S77.C 
[1570.0,1590.0,1609.0.1625.0, 1634.0,1635.0, 1628.0, 1609.0,1582.0,1549.0,1511.0, 1471.0, 1432.C 
[1042. 0,1038.0, 1035.0, 1034.0, 1032.0, 1031.0, 1033.0, 1036.0, 1039.0, 1045. 0,1053.0, 1061.0, 1069.C 
[1296.0,1341.0,1405.0,1494.0, 1613.0,1766.0, 1948.0,2148.0.2352.0,2544.0,2711.0.2846.0.2943.C 
[1866.0, 1792. 0,1725. 0,1667.0, 1618.0, 1580.0, 1554.0, 1539.0, 1535. 0,1540. 0, 1551. 0, 1569.0, 1590.C 
[1188.0,1167.0,1148.0,1130.0, 11 13. 0,1098. 0,1084. 0, 1071.0, 1061.0, 10S3.0, 1046. 0,1040. 0,1036. ( 
[1123.0, 1134.0, 1144. 0,1156.0, 1169.0, 1181.0,1191.0, 1202. 0,1215.0, 1232.0, 1254.0, 1283.0.1322.C 
[2802.0,2725.0,2642.0,2555.0,2468.0,2380.0,2294.0,2211.0,2090.0,2011.0.1935.0, 1790.0, 1726.C 
[1391.0, 1358.0,1327.0, 1299.0, 1273.0, 1250.0, 1228.0, 1208.0, 1188.0,1 168. 0,1 148.0, 1127.0, 1108.C 
[1085. 0,1087.0, 1087. 0,1087.0, 1088.0, 1089.0, 1094.0, 1103. 0,1116.0, 1131. 0,1 147.0, 1163.0, 1178.C 
[3012. 0,3038.0, 3042. 0,3026.0, 2994.0, 2949.0, 2894.0, 2830.0, 2757.0, 2677.0, 2594.0, 2509.0, 2423.C 
[1608.0, 1621.0,1628.0,1627.0, 1619.0,1603.0, 1580.0, 1550.0, 1516.0,1480.0,1444.0, 1410.0, 1377.C 
[1038.0, 1037.0,1038.0, 1040.0, 1043.0, 1046.0, 1049.0, 1053.0, 1056.0,1058.0, 1061.0,1065.0, 1069.C 
[1380.0, 1461.0, 1573.0, 1718.0, 1893.0, 2091.0, 2298.0, 2496.0, 2672.0, 2816.0, 2922.0, 2991.0, 3029.C 
[1746.0, 1689.0, 1638.0, 1594.0, 1561.0, 1540.0, 1530.0, 1532. 0,1544.0, 1564. 0,1588.0, 1610.0, 1627.C 
[1156.0,1133.0,1113.0, 1096.0, 1082.0,1071.0, 1062.0,1053. 0.1046.0,1040.0,1036.0.1033.0.1031.( 
[1132. 0,1143.0,1155.0, 1168.0, 1182.0, 1197.0, 1212.0, 1227.0, 1247.0,1273. 0,1308.0, 1357.0, 1428.C 
[2670.0, 2585.0, 2498.0, 2410.0, 2324.0, 2239.0, 2156.0, 2075. 0,1996.0, 1917.0,1842.0, 1771.0, 1707.C 
[1473.0, 1437.0,1404.0,1372.0, 1341.0, 1312.0, 1283.0, 1255. 0,1228.0, 1202.0, 1178.0,1156.0, 1136.C 
[1064.0, 1066.0, 1067.0, 1069.0, 1072.0, 1076.0, 1082.0,1090.0, 1100.0,1110.0,1121.0, 1134.0, 1146.C 
[2824.0, 2929.0, 2999.0, 3037.0, 3049.0, 3039.0, 3012.0, 2970.0, 2916.0, 2852. 0,2780.0, 2702.0, 2618.C 
[1037.0, 1032.0, 1028.0, 1026.0, 1026.0, 1028.0, 1032.0, 1038.0, 1044.0, 1050.0, 1056.0, 1062.0, 1068.C 
[1277.0,1312.0,1363.0,1437.0, 1540. 0,1676.0, 1844. 0,2037. 0,2  243. 0,2446. 0,2  628. 0,2  778. 0,2892. ( 
[  1904. 0, 1829. 0,1 761. 0. 1700. 0,1647. 0, 1605. 0, 15  74. 0,15  53. 0,1542. 0,1 540. 0, 1547. 0,1 56 1.0.1579.C 
[1208.0,1184.0,1161.0.1141.0,1123.0f1107.0,1093.0,1080.0,1068.0,1058.0,1050.0,1043.0,1037.( 
[1106.0, 1117.0, 1130.0, 1143.0, 1157.0, 1170.0, 1182.0, 1193. 0,1205. 0,1220.0, 1238.0, 1262.0, 1295.C 


Figure  3:  Logged  Waveform  Data 
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Metric 

Instance 
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EKQDA2fTwCkQAQDkys0bp4iJyF<JJ24Otai™F 

MDC_RESP_RATE 

0 

@Fii  {EOT) 

{'SK":14093W972,"nar»sec^6K4000000}},@M  Aug  29  2014  1 3; 56: 14 GMTM1C  (HOT) 

{ ’value’ :  la/devicejime'-rsec* :  1 4 09334 974/ names  ec’ :75000000>},@Ri  Aug  29  20 14  13:56:  1 5 
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0400  (EDT)  { "value":  1 19 ."device  time':{’sec"®."nanosec":0}>,®Fn  Aug  29  2014  13:56:16 

G MT-0400  (EDT)  {’’vali»e':119,,devioe_tiirK":{"secp:0,'nano5K,':0}}7@FTi  Aug  29  2014 

13:56:17  GMT-0400  (EDT)  {" value’:  1 19,’device_time"’:{’ sec ':0,’nancsec':0}>,@Fri  Aug  29 

2014  13:56:18  GMT-0400  (EOT)  {"value’ :1  ]  9,’devipe_tirrie’:{psec,3),"  nanosec"  :0>>.@Fri  Aug 
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Figure  4:  Data  Samples  with  UDI  &  Time  Stamps 
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It  is  important  for  us  to  quantify  the  maximum  data  throughput  of  the  system.  This  will  ultimately 
be  limited  by  the  speed  of  the  data  storage  system,  and  these  results  will  allow  us  to  specify  the 
storage  requirements  for  individual  ICE  data  loggers  and  also  for  an  architecture  where  all  ICE 
data  is  backed  up  in  a  central  data  store  at  the  Healthcare  Delivery  Organization. 

The  NIST  team  visited  our  lab  in  March  as  part  of  a  three-day  SmartAmerica  “hackathon”  (see 
http://mdpnp.org/smartamerica.php),  and  we  collaborated  with  them  to  connect  to  our  OpenICE 
platform  to  collect  data.  Based  on  the  research  results  to  date,  NIST  re-worked  their  prototype 
data  logger  to  work  with  DDS,  and  demonstrated  it  at  the  SmartAmerica  Expo  prep  meeting  in 
May.  They  presented  their  latest  work  on  the  prototype  data  logger  and  analysis  system, 
followed  by  a  demonstration  of  that  system  running  on  a  PC  as  well  as  an  iPad  interfaced  to  that 
system. 

Our  continued  work  on  developing  core  OpenICE  infrastructure  includes  a  framework  that 
allows  for  data  logging  without  compromising  system  security  or  patient  privacy.  In  collaboration 
with  NIST,  we  are  performing  research  on  the  best  approach  to  long-term  storage  of  logged 
data  that  will  facilitate  forensic  analysis  of  adverse  events  or  other  events  of  interest.  We  are 
performing  experiments  to  compare  the  performance  of  MySQL  and  other  data  stores  for 
recording  and  searching  data.  This  allows  us  to  perform  end-to-end  testing  of  the  entire 
OpenICE  system  from  the  equipment  interface  through  to  the  Data  Logger  as  we  revise  our 
OpenICE  platform. 

The  privacy  and  security  of  patient  data  are  now  major  areas  of  focus.  We  have  worked  with 
MGH  IT  staff  to  stand  up  a  new  server  to  support  the  logging  of  large  amounts  of  protected 
patient  data  in  a  secure  environment.  This  server  is  hosted  in  the  Partners  Data  Center  and  will 
be  available  for  storing  data  collected  during  clinical  research  trials. 

Since  the  FDA  Unique  Device  Identifier  (UDI)  ruling  was  published  on  September  24  2013,  we 
have  been  exploring  how  to  use  the  data  format  and  content  identified  in  the  ruling  within  our 
OpenICE  implementation.  The  UDI  ruling  lists  information  that  must  be  printed  on  the  packaging 
of  medical  devices,  but  it  does  not  address  electronic  communications.  Dr.  Goldman  has  been 
part  of  a  group  convened  by  the  Brookings  Institute  to  discuss  capturing  unique  device 
identifiers  (UDIs)  in  administrative  health  care  claims.  As  part  of  the  UDI  Implementation  Work 
Group,  we  have  been  in  discussions  with  FDA  and  Brookings  about  prototyping  electronic 
communication  of  UDIs  and  the  role  of  UDI  in  interoperable  systems,  and  we  are  in  the  process 
of  determining  how  to  extend  our  current  UDI  implementation  with  additional  information  from 
the  ruling.  This  will  enhance  our  data  logger  and  playback  with  additional  information  about  the 
device  manufacturer,  manufacturing  date,  batch  ID,  and  so  on.  We  plan  to  complete  and  test 
this  expanded  UDI  implementation  during  the  remaining  months  of  this  Option-Year  and  provide 
our  results  to  the  FDA. 

Clinical  Scenario  Repository,  Aim  2:  Develop  a  sharable  repository  of  clinical  scenarios  that 
could  be  improved  through  better  medical  device  and  health  IT  integration. 

During  the  first  year  of  this  award,  we  leveraged  the  work  done  under  TATRC  award  W81XWH- 
09-1-0705  to  build  and  test  a  robust  preliminary  web-based  prototype  of  the  Clinical  Scenario 
Repository  (CSR™).  An  alpha  version  prototype  was  developed,  tested  and  shared  among 
internal  collaborators,  who  provided  valuable  feedback.  The  culmination  of  our  first  year’s  work 
was  the  opportunity  to  show  the  alpha  version  of  the  prototype  Clinical  Scenario  Repository 
when  we  presented  a  series  of  demonstrations  of  our  work  at  NIH  on  August  21-22  2013  for 
invited  representatives  from  federal  agencies.  There  were  over  60  attendees  from  DoD,  FDA, 
NIST,  NIH,  and  other  federal  agencies,  and  we  received  positive  feedback,  encouraging  us  to 
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develop  additional  features,  e.g.  advanced  search  capabilities  that  might  include  an  ontology  of 
terms  and  use  of  natural  language  processing  of  submitted  text  to  auto-create  keyword  tags. 
Subsequently,  the  prototype  repository  was  presented  several  times  as  part  of  our  Lab  Open 
House  tours  in  September  2013  and  other  demonstrations  of  our  work  to  visitors  and 
collaborators. 

In  preparation  for  the  initial  limited  beta  test,  the  functionality  of  the  CSR™  was  greatly 
enhanced.  While  some  of  these  features  reflected  needs  we  had  already  identified  internally, 
many  of  them  were  the  direct  result  of  the  feedback  from  federal  attendees  at  the  August 
technology  demonstrations.  We  were  careful  to  implement  the  requested  features  in  a  way  that 
protects  health  information,  while  also  responding  to  user  expectations  regarding  usage  and 
functionality.  One  challenge  that  surfaced  in  the  August  demos  was  related  to  a  suggestion  that 
repository  users  be  able  to  annotate  existing  scenarios  and  increment  the  information  contained 
within  scenarios  -  this  kind  of  feature  raised  issues  about  governance  of  the  data  contained  in 
the  repository,  and  underscored  the  need  for  a  process  that  enforces  our  policy  of  not  including 
any  personal  or  defamatory  information  in  the  scenarios. 

The  beta  version  of  the  CSR™  was  released  in  December  2013  to  a  pilot  group  of  internal  MGH 
users,  has  been  shown  to  several  groups  visiting  the  MD  PnP  Interoperability  Lab  (including 
standards  development  committees  and  industry),  and  was  shown  publicly  to  clinicians  and 
engineers  at  the  annual  meeting  of  the  Society  for  Technology  in  Anesthesia  (STA)  in  January 
2014.  The  CSR™  had  considerable  exposure  at  STA  -  it  was  one  of  the  hands-on  stations  in 
our  two-hour  OpenICE  workshop,  and  was  presented  in  a  lecture  and  poster.  The  CSR™  had 
also  been  presented  in  a  panel  with  Hopkins  and  Mayo  at  the  Society  for  Critical  Care  Medicine 
meeting  in  San  Francisco  the  week  prior  to  STA. 

We  received  many  new  ideas  and  requests,  as  well  as  feedback,  from  STA.  Both  clinical  and 
industry  users  expressed  concern  about  information  that  the  CSR™  could  make  available  to  the 
general  public  on  specific  medical  device  models  and  products,  e.g.  possible  malfunctioning, 
less  competitive  array  of  functionality  and  features,  general  problems,  etc.  While  some 
manufacturer  representatives  expressed  interest  in  using  the  content  of  the  repository  as 
feedback  to  verify  product  functionality  and  address  new  features  or  product  opportunities,  they 
also  proposed  restricting  access  to  the  CSR™  content  to  the  QA  departments  of  hospitals  and 
companies.  This  confirmed  our  own  concerns  about  the  extent  of  governance  issues  to  be 
addressed,  and  about  taking  additional  cautionary  measures  with  the  scenario  approval 
workflow. 

While  we  had  anticipated  the  need  for  an  approval  process  that  could  validate  the  content  of 
CSR™  submissions  before  making  the  scenarios  available  to  all  users,  additional  aspects  of  the 
governance  process  surfaced.  For  example,  STA  attendees  pointed  out  that  making  sure  that  a 
scenario  does  not  contain  any  specific  defamatory  information  (names  of  doctors,  hospitals, 
etc.)  is  not  enough  to  guarantee  the  lack  of  defamatory  information  -  the  CSR™  cannot  have 
any  kind  of  implicit  defamatory  information  that  could  be  derived  from  the  content  posted. 
Moreover,  we  are  reevaluating  the  consequences  of  opening  a  tool  like  the  CSR™  to  the 
general  public  -  while  it  is  our  intent  that  this  repository  does  not  substitute  for  other  medico¬ 
legal  and/or  regulatory  mechanisms,  there  may  nonetheless  be  submissions  that  would  require 
CSR™  administrators  to  act  upon  receiving  them,  e.g.  mention  of  suicide  attempts  or  child 
molestation.  This  has  underscored  the  importance  of  our  governance  approach  and  process. 

We  are  considering  how  the  clinical  scenarios  in  the  CSR™  can  be  cross-referenced  with  other 
databases  and  with  our  other  project  work,  e.g.  linking  to  further  documentation  of  ConOps 
(engineering  Concept  of  Operations)  or  requirements.  In  the  future,  we  may  also  expand  the 


August  2014 


8 


CSR™  to  include  the  other  artifacts  that  are  necessary  to  follow  a  scenario  all  the  way  to 
implementation. 

An  important  milestone  accomplished  during  the  past  quarter  involved  successfully  deploying 
the  CSR™  web  application  on  our  own  managed  servers,  moving  away  from  the  Google 
Application  Engine  that  was  used  in  the  prototype’s  early  stages.  This  will  help  prepare  for  a 
broader  MGH  pilot. 

The  MD  PnP  Program  had  already  tested  different  technologies  to  carry  out  this  migration  (e.g. 
the  Hibernate  framework  to  persist  Java  objects  into  a  MySQL  database,  and  Oracle’s 
GlassFish  open-source  application  server  to  serve  the  web  application).  We  tested  simple 
functionality  to  gain  better  insights  into  both  the  newer  technical  requirements  brought  by  the 
migration  and  the  consequences  of  choosing  one  technology  over  others.  During  the  past 
quarter,  the  team  considered  security  and  performance  aspects  such  as  acquiring  digital 
certificates  to  encrypt  data  sent  between  the  user’s  web  browser  and  our  servers,  work  that 
aligns  perfectly  with  the  needs  of  the  CSR™. 

Ensuring  adequate  authentication  and  authorization  mechanisms  is  one  of  the  CSR™  priorities 
that  is  still  under  development.  Several  promising  technologies  have  been  considered  for  this 
task,  including  Spring  Security,  a  powerful  and  highly  customizable  authentication  and  access 
control  framework,  and  BCrypt,  the  Java  implementation  of  a  hashing  algorithm  that  would  allow 
for  hashing  a  password  (ensuring  that  users’  passwords  and  other  sensitive  data  are  not  stored 
using  plain  text  in  the  database)  and  SSL  certificates. 

The  process  of  migrating  the  CSR™  away  from  the  Google  Application  Engine  has  led  to  a 
revision  of  the  necessary  capabilities  for  the  system  and  the  interfaces  needed  to  implement 
them.  As  feedback  indicated  that  the  earlier  tabbed  interface  for  “Scenario  Submission ”  was 
considered  a  burdensome  process,  we  sought  further  insights  into  how  users  of  diverse  clinical 
and  technological  expertise  levels  or  professional  backgrounds  try  to  enter  relevant  information 
into  a  reporting  system  such  as  the  CSR™. 

Figures  5  and  6  show  screenshots  of  the  current  prototype  interface  for  submitting  a  scenario.  In 
order  to  facilitate  the  scenario  submission  process,  we  have  divided  it  into  different  stages.  The 
first  step  is  a  description  of  the  problem,  which  is  the  minimum  information  for  entering  a  clinical 
scenario.  After  completing  this  basic  information,  the  user  can  opt  to  add  extra  details  to  their 


story  in  Step  #2. 


Figure  5:  Scenario  Submission  Prototype  Interface  (Step  #1) 
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Step  2  (optional):  Add  additional  information  about  the  scenario. 

Add  further  details  about  contributing  actors  or  events  that  happaned  or  could  happen  in  this  kind  of  scenario. 

No  fields  are  mandatory.  Complete  the  information  in  the  tabs  that  you  think  is  relevant  for  the  case  and  submit  when  it  is  ready. 

Hazards  and  Dangers  Equipment:  Related  Software  Equipment:  Related  Hardware  Roles  Involved  Places  Involved  Lessons  Learned  References 

Add  online  links  to  relevant  internet  references  for  this  scenario 

http://  Delete  | 

Add  New  Reference 


Go  Back  to  Basic  Information  |  Save  |  Finish  and  Submit  | 


Figure  6:  Scenario  Submission  Prototype  Interface  (Step  #2) 

This  approach  provides  a  common  starting  point  for  all  users,  with  an  easy  and  basic  first  step 
followed  by  optional  steps  to  enhance  the  scenario.  We  hope  that  a  multi-step  workflow  will 
facilitate  users’  understanding  and  comfort  level  with  the  process,  especially  for  users  who 
might  feel  overwhelmed  with  the  technology  or  with  how  much  extra  information  could  be 
associated  with  a  scenario. 

We  are  revisiting  whether  a  “possible  solution”  description  should  be  added  as  a  step  of  the 
scenario  submission  process  or  in  a  different  way.  Potential  optimizations  and  changes  in 
functionality  and  interfaces  need  to  be  considered  carefully,  which  has  slowed  the  migration 
process  but  has  provided  a  useful  review  of  system  functionality. 

We  are  considering  new  approaches  for  other  system  capabilities.  For  example,  instead  of 
making  an  administrator-approved  scenario  visible  to  the  general  public,  we  may  want  to 
maintain  the  confidentiality  of  information  such  as  the  manufacturer  or  model  of  the  devices 
involved.  This  device  information  could  be  made  available  for  research,  but  not  for  the  general 
public,  thus  eliminating  the  risk  of  publicly  implying  that  a  specific  model  does  not  perform  as 
expected.  In  the  next  several  months,  we  will  complete  evaluation  and  implementation  of  the 
CSR™  functionality  and  bring  the  second  prototype  to  beta  status. 

While  we  are  reimplementing  the  CSR™,  collaborators  still  have  access  to  the  previous  beta 
version  and  are  continuing  to  provide  valuable  feedback. 

We  have  begun  to  investigate  potential  opportunities  to  align  the  CSR™  with  the  recently 
released  OpenFDA  APIs  (https://open.fda.gov/),  and  we  will  also  look  at  potential  integration 
with  other  frameworks.  We  are  also  focusing  on  obtaining  the  appropriate  authentication  and 
authorization  mechanisms  needed  for  the  governance  process. 

The  unique  attributes  of  this  CSR™  -  i.e.  not  linked  to  a  single  medical  device  failure  (like  FDA 
MAUDE),  not  required  to  have  a  1:1  relationship  between  a  scenario  event/idea  and  submission 
(like  hospital  and  insurance  reporting),  not  linked  to  a  specific  patient  (or  any  patient),  free  text 
entry,  etc.  -  opens  the  door  for  a  new  approach  to  healthcare  quality  improvement.  Even  before 
general  release,  this  CSR™  is  generating  excitement  and  the  contribution  of  ideas  by  leaders 
from  industry,  patient  safety,  and  clinical  domains.  We  envision  even  more  interest  when  the 
CSR™  is  publicly  released.  Moreover,  we  expect  a  linkage  will  develop  between  this  work  and 
the  new  Federal  initiatives  around  device/HIT  safety,  such  as  FDASIA,  and  new  initiatives  at  the 
Brookings  Institute  and  at  Duke.  TATRC’s  longtime  support  of  this  project  reflects  an  early  and 
continuing  vision  and  has  enabled  us  to  be  way  ahead  of  the  curve  in  this  important  area. 
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Open  Source  Code  Dissemination,  Aim  3:  Disseminate  open-source  code  developed  by  the 
MD  PnP  program  and  collaborators,  including  the  prototype  Data  Logger,  in  order  to  facilitate 
further  development  by  others. 

The  MD  PnP  application  code-sharing  site  on  SourceForge  (http://mdpnp.sourceforqe.net)  saw 
955  downloads  of  our  prototype  Open  ICE  platform  and  tools  over  the  past  year  (see  Figure  7 
below).  Anyone  who  downloads  that  software  package  can  use  our  simple  device  simulators  to 
begin  development  of  clinical  apps  for  the  platform.  In  addition  to  sharing  with  the  public  at 
large,  we  have  engaged  in  specific  interactions  to  pave  the  way  for  development  of  the  first  ICE 
AX  apps  as  well  as  the  first  frameworks.  We  continue  to  balance  supporting  these  nascent 
external  activities  against  our  need  to  use  insights  gained  to  enhance  and  iterate  on  the  platform 
itself.  With  each  engagement  we  are  also  streamlining  the  documentation  of  the  platform  to 
immediately  surface  its  value  to  groups  who  might  benefit  from  its  use  for  clinical  research. 


o 


«wlJnique  Visitors  Software  Downloads 


Figure  7:  Weekly  Open  Source  Activity  on  MD  PnP  SourceForge  Site 

A  researcher  at  the  University  of  Florida  at  Gainesville  has  successfully  downloaded,  built  and 
run  our  code  from  SourceForge;  he  is  building  a  system  for  automatic  patient  assessment  using 
our  public  Philips  interfaces  and  DDS  backbone.  His  team  was  unable  to  implement  the  desired 
system  without  our  tools  and  support.  In  working  with  them  we  realized  that  our  current  interface 
software  utilizing  the  device’s  Ethernet  port  would  not  be  usable  with  a  monitor  connected  to  its 
central  station  in  such  a  study,  so  we  rewrote  our  interface  to  also  support  direct  RS-232 
connection  to  the  monitor. 

In  November  the  MD  PnP  Lab  hosted  undergraduate  students  from  Harvard  and  MIT  for  a 
“hack-a-thon”  organized  in  conjunction  with  the  Hacking  Medicine  group.  This  gave  us  the 
opportunity  to  expose  our  platform  work  to  students  who  were  tasked  with  creating  innovative 
healthcare  apps  based  on  problem  areas  we  outlined.  While  it  was  difficult  for  the  students  to 
produce  complete  apps  within  the  time  constraints  of  the  event,  several  students  expressed 
interest  in  returning  to  the  lab  and  utilizing  both  our  physical  equipment  and  software  platform 
for  further  work. 
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Researchers  at  the  United  States  Army  Institute  of  Surgical  Research  have  been  analyzing  the 
SourceForge  code  and  our  approach  to  data  integration.  We  have  begun  technical  discussions 
and  code  sharing,  and  we  expect  this  work  to  expand. 

In  the  area  of  frameworks,  we  became  better  connected  with  pre-release  work  being  done  at 
Mathworks  Inc.  on  a  MatLab  interface  to  RTI’s  DDS  middleware.  By  involving  ourselves  in  that 
project  now,  we  can  ensure  that  when  this  MatLab  “BlockSet”  is  eventually  released,  it  will  be 
compatible  with  and  allow  access  to  our  ICE  platform  for  MatLab  users.  We  will  have  some 
examples  and  documentation  prepared  in  advance  of  that  release.  We  have  also  been  in 
contact  with  an  anesthesiologist  at  Loma  Linda  University  Medical  Center  who  is  interested  in 
helping  provide  a  framework  for  the  use  of  those  who  wish  to  integrate  their  iOS  (iPad  and 
iPhone)  devices.  He  would  like  to  develop  this  framework  in  anticipation  of  his  own  app 
development  in  the  area  of  smart  alarms. 

We  are  continuing  our  association  with  Open  Health  Tools  -  we  hosted  their  board  meeting  in 
September  2013,  including  a  tour  of  our  Interoperability  Lab. 

After  seeing  our  demos  at  NIH  in  August,  Tim  Rajah  at  the  NIH  Clinical  Center  wanted  to  use 
OpenICE  to  collect  data  from  Philips  patient  monitors.  We  provided  a  BeagleBone  and  despite 
substantial  remotely  provided  technical  support,  the  outdated  Philips  monitor  software  could  not 
connect.  Our  two  senior  engineers  spent  a  day  at  the  NIH  CC  in  February,  and  set  up  a 
complete  OpenICE  system  (laptop,  network  switch,  and  device  adapters)  that  can  successfully 
obtain  data  from  the  old  Philips  monitor. 

The  Office  of  the  National  Coordinator  for  Health  IT  invited  us  to  participate  again  this  year  in 
their  area  of  the  Interoperability  Showcase  at  the  annual  Healthcare  Information  &  Management 
Systems  Society  (HI MSS)  conference  and  exhibition  in  Orlando  in  February.  We  developed  a 
new  ICE  application  for  this  demonstration  that  runs  on  Android  tablets  and  smartphones  and 
streams  physiological  data  (including  waveforms)  from  medical  devices  connected  at  our  lab  in 
Cambridge,  MA,  as  well  as  data  from  medical  devices  connected  locally.  While  much  of  our 
ongoing  work  focuses  on  the  patient  bedside,  we  wanted  to  demonstrate  to  the  HIMSS 
audience  how  a  bedside  ICE  network  can  connect  to  external  resources.  For  this  demo  we  built 
a  prototype  ICE  External  Interface  suitable  for  live  streaming  data,  an  Android  app  to  display  the 
data,  and  an  ICE  application  that  packages  up  the  data  and  sends  it  to  the  phone  or  tablet.  We 
had  the  opportunity  to  show  this  demonstration  to  the  new  National  Coordinator  for  Health  IT, 

Dr.  Karen  DeSalvo,  and  to  Col.  Dan  Krai  and  others  from  TATRC,  as  well  as  to  many  other 
attendees  over  the  course  of  three  days. 
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National  Coordinator  for  Health  IT,  Dr.  Karen  DeSalvo 
at  MD  PnP  Demonstration,  “Real-Time  Blue  Button  for  Patients  and  Families” 
ONC  Area  of  HIMSS  Interoperability  Showcase,  February  2014 


This  type  of  system  is  suitable  for  remote  display  of  patient  data,  including  waveforms  and 
alarms,  and  could  be  used  either  for  live  display  or  for  streaming  data  to  a  research  database.  A 
robust  ICE  system  constitutes  a  more  informative  peer  to  other  hospital  systems.  For  example, 
an  electronic  medical  record  (EMR)  system  could  archive  real-time  data  from  the  ICE  system. 
The  EMR  can  also  benefit  from  the  richer  set  of  information  provided  by  ICE  as  compared  with 
individual  devices.  At  HIMSS  we  demonstrated  that  even  patient  engagement  systems,  such  as 
those  inspired  by  the  VA  Blue  Button  initiative,  can  benefit  from  the  availability  of  the  suite  of 
rich  contextual  data  made  available  in  real  time  by  an  ICE  system.  A  video  of  this  demo  is 
available  at  http://vimeo.com/87434601 . 

In  March  we  hosted  the  Closed  Loop  Healthcare  team  participating  in  the  Presidential 
Innovation  Fellows’  SmartAmerica  Challenge.  During  the  three-day  meeting  and  “hackathon”  in 
our  lab,  we  made  progress  with  a  number  of  collaborators.  The  team  from  NIST  was  able  to 
streamline  the  acquisition  of  data  for  later  replay  by  their  playback  application  for  the  ICE  Data 
Logger.  They  have  acquired  a  Philips  patient  monitor,  so  we  configured  a  BeagleBone  for  them 
with  an  ICE  Equipment  Interface  for  further  testing  and  development.  We  also  had  an 
opportunity  at  the  SmartAmerica  event  to  bring  together  two  vendors  of  DDS  middleware,  RTI 
and  PrismTech,  to  demonstrate  interoperability  between  their  implementations.  We  discovered 
a  few  small  incompatibilities  (due  to  configuration)  and  remedied  them  in  the  course  of  the 
meeting.  Our  Closed  Loop  Healthcare  collaborators  shared  integration  strategies  at  the 
enterprise  level,  both  for  data  integration  and  for  data  storage.  The  prototype  developed  during 
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the  March  hackathon  was  demonstrated  at  the  White  House-hosted  SmartAmerica  Expo  in 
Washington,  DC  in  June. 

The  ICE  External  Interface  prototype  we  built  for  our  HIMSS  demo  was  highly  customized  to 
that  application  and  not  suitable  for  large  numbers  of  patients  or  client  applications.  We  have 
been  working  to  connect  ICE  to  a  generalized  Enterprise  Service  Bus  (ESB).  While  DDS  is  a 
great  backbone  for  a  high-criticality  distributed  system,  our  connection  to  an  ESB  creates 
alignment  between  our  system  and  a  library  of  modular  components  for  exposing  ICE  data  to 
other  systems  via  a  wide  range  of  existing  technologies. 

In  April  two  members  of  our  team  presented  our  work  at  the  International  Conference  on  Cyber- 
Physical  Systems  (ICCPS)  in  Berlin.  Our  short  paper  describing  key  considerations,  or  pillars, 
for  selecting  middleware  for  ICE  systems  was  presented  at  the  workshop  on  Medical  Cyber- 
Physical  Systems.  A  poster  describing  our  work  on  OpenICE  was  presented  during  the  ICCPS 
poster  session.  We  received  considerable  interest  from  members  of  the  CPS  community  who 
understood  that  they  need  common  data  streams  to  enable  their  work  on  closed-loop  control 
systems.  At  the  workshop  we  also  presented  a  poster  describing  our  work  on  gathering  clinical 
requirements,  as  well  as  our  Clinical  Scenario  Repository  (CSR™).  A  number  of  participants 
expressed  interest  in  the  description  of  clinical  scenarios,  and  some  participants  plan  to  become 
beta  testers  of  the  CSR™. 

At  the  request  of  the  Presidential  Innovation  Fellows  who  organized  the  SmartAmerica 
Challenge,  MD  PnP  also  announced  in  June  2014  the  SmartAmerica  /  MD  PnP  Healthcare  App 
Challenge  (SAMHAC),  enabled  by  our  construction  of  a  web-facing  WebSocket  API  for 
accessing  data  from  our  lab  testbed  environment.  As  part  of  the  contest  launch,  we  showed  a 
demonstration  “app”  running  in  several  different  web  browsers  and  on  several  types  of  devices 
streaming  physiological  data  from  medical  devices  in  our  lab  in  Cambridge,  MA.  The  Gordon  & 
Betty  Moore  Foundation  has  donated  $30K  in  prize  money  for  the  App  Challenge.  The  idea  has 
drawn  the  attention  of  HSS,  who  will  now  be  hosting  it  on  challenge.gov  with  a  new  timeline  to 
be  announced  in  September  2014. 

External  Interfaces  for  Bi-Directional  Data  Transfer,  Aim  4:  Define  and  document  external 
interfaces  to  bi-directionally  transfer  medical  device  and  patient  contextual  data  between  the 
integrated  clinical  environment  and  external  systems  of  national  interest. 

In  socializing  the  concept  of  remote  bi-directional  connectivity  to  our  MD  PnP  Interoperability 
Lab,  we  have  found  that  there  is  great  interest  in  this  capability,  especially  as  a  means  to 
provide  simulated  data  to  computer  science  and  engineering  research  groups  that  have  limited 
access  to  clinical  devices,  data,  and  domain  expertise.  In  addition  to  working  on  collaborations 
with  UIUC  and  UMass  Amherst,  we  responded  to  the  initial  White  House  SmartAmerica 
Challenge  with  a  white  paper  proposing  a  “Virtual  Hospital  CPS  Test  Bed”  building  directly  on 
Aim  4  of  this  award;  this  led  to  inclusion  of  Dr.  Goldman  in  the  SmartAmerica  Challenge  meeting 
held  at  the  White  House  in  December  2013. 

This  concept  of  using  our  interoperability  lab  as  a  test  bed,  including  remote  bi-directional 
connectivity,  gained  considerable  momentum  this  year.  There  has  been  specific  interest  from 
both  the  White  House  (OSTP)  and  NSF.  As  a  result  of  his  presentation  of  the  “Virtual  Hospital 
CPS  Test  Bed”  at  the  White  House  SmartAmerica  Challenge  in  December,  Dr.  Goldman 
became  co-chair  of  the  Closed-Loop  Healthcare  team  formed  there.  During  a  three-day  meeting 
and  “hackathon”  in  our  lab  in  March,  the  team  implemented  some  specific  scenarios  and 
prepared  to  demonstrate  them  at  a  SmartAmerica  Expo  in  Washington  DC  in  June.  We  also 
incorporated  data  transfer  through  a  bi-directional  interface  in  our  HIMSS14  demonstration  in 
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February  (see  Aim  3  above).  Widespread  interest  is  developing  around  this  test  bed  concept  as 
a  means  to  provide  simulated  data  to  research  groups. 

Hospitals  do  not  typically  have  a  monolithic  record  system  requiring  only  a  single  interface. 
Instead,  there  are  large  catalogs  of  available  services,  each  with  its  own  specification.  Thus, 
developing  bilateral  interfaces  between  ICE  and  each  of  these  services  individually  would  be  a 
dead-end  for  development.  Instead  we  have  worked  to  integrate  a  DDS  system  into  a  larger 
Enterprise  Service  Bus.  Aligning  ourselves  with  ongoing  work  by  DDS  vendors,  we  have  worked 
with  Apache  Camel  to  create  an  endpoint  for  our  system.  Camel  allows  us  to  align  our  system 
interface  with  interfaces  to  myriad  other  systems  without  any  tight  coupling.  For  example,  our 
Camel  interface  could  be  connected  to  the  Camel  component  for  HL7  to  interface  with  an 
Electronic  Health  Record  (EHR).  With  a  simple  reconfiguration,  we  could  also  use  150  other 
Camel  components,  allowing  us  to  connect  with  systems  via  technologies  ranging  from  flat  files 
to  web  services.  We  have  connected  our  Camel  interface  with  the  Camel  component  for 
“websockets”,  which  are  bidirectional  protocols  for  streaming  data  to  a  web  browser  client.  Such 
an  interface  allows  us  to  easily  export  data  from  ICE  to  a  wide  range  of  other  terminals  running 
on  desktops,  laptops,  tablets,  and  smartphones.  We  expect  that  this  will  be  a  viable  pathway  for 
making  the  type  of  interface  shown  in  our  Real-Time  Blue  Button  HIMSS  demo  publicly 
available. 

Connecting  with  external  systems  has  matured  our  approach  to  handling  multiple  patients. 
Within  the  scope  of  a  single  ICE  instance,  only  a  single  patient  is  involved,  but  most  external 
systems  are  managing  entire  patient  populations.  Elaborating  on  how  many  ICEs  will  be 
coordinated  has  also  aided  our  ability  to  communicate  with  health  information  technology 
experts,  bridging  a  gap  and  demonstrating  the  relevance  of  ICE  to  the  real  world  systems  that 
drive  clinical  environments  today. 

Our  understanding  of  potential  interactions  between  ICE  and  other  hospital  systems  has  also 
matured  greatly  this  year.  We  have  been  working  with  a  developer  at  MGH  to  understand  the 
catalog  of  currently  available  test  interfaces.  Partners  Healthcare  (and  MGH  as  a  Partners 
hospital)  is  in  the  process  of  changing  electronic  health  record  systems,  a  large  undertaking  that 
is  expected  to  take  at  least  five  years.  This  change  means  that  all  of  the  interfaces  to  the  EHR 
will  be  changing,  with  the  first  round  of  changes  scheduled  for  July.  This  is  not,  therefore,  a 
good  time  to  prototype  new  connections  to  MGH  systems,  and  has  resulted  in  our  not  being 
able  to  perform  the  work  needed  for  our  milestone  related  to  the  ADT  systems.  However,  we 
have  been  learning  about  the  new  systems  that  are  being  installed  and  how  to  obtain  access  to 
the  new  test  data  feeds  as  they  are  started,  so  we  hope  to  perform  this  work  at  an  appropriate 
later  time.  As  an  alternative  to  connecting  to  MGH’s  test  services,  we  have  been  working  with 
support  from  the  United  States  Department  of  Veterans  Affairs  (VA)  to  install  the  OSEHRA 
Veterans  Health  Information  Systems  and  Technology  Architecture  (VistA)  in  our  lab. 

VistA  is  an  enterprise-wide  information  system  built  around  an  EHR  used  throughout  the  VA 
medical  system.  It  consists  of  nearly  160  integrated  software  modules  for  clinical  care,  financial 
functions,  and  infrastructure.  Our  team  at  MD  PnP  has  chosen  to  test  ICE  integration  with  VistA, 
as  it  is  a  widely  used  EHR  in  the  U.S  and  is  freely  available  as  an  open-source  program.  There 
are  several  VistA  variants  available.  We  have  been  working  with  OSEHRA  (Open  Source 
Electronic  Health  Record  Alliance)  to  install  OSEHRA  VistA.  In  the  past  quarter,  we  installed  the 
client-server  packages  of  Astronaut-VistA  and  have  successfully  used  the  command  line 
interface  to  access  and  manipulate  the  data  on  the  server.  We  installed  the  GUI  based  client 
application  called  CPRS  (Computerized  Patient  Record  System). 
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The  various  versions  and  fixes/patches  available  for  Astronaut-VistA  have  been  developed  by 
an  open  source  community  and  have  many  bugs.  The  client-server  versions  that  are  publically 
available  do  pair  up  well.  We  are  currently  approaching  experts  in  this  field  to  guide  us  with  the 
configuration  of  a  reliable  system.  We  have  been  working  closely  with  the  development  team  at 
OSEHRA  to  get  VistA  installed  and  functional  in  the  MD  PnP  Lab.  At  this  point,  the  basic  system 
is  installed  and  running,  and  we  are  working  with  OSEHRA  to  understand  the  many  possible 
ways  of  integrating  VistA  with  the  lab.  We  next  plan  to  export  an  ADT  feed  from  the  EHR  to  the 
lab  and  will  add  the  ability  to  import  device  data  for  logging  and  analysis  from  medical  devices  in 
our  lab. 

Milestones: 


Milestone 

Aim 

Qtr  Due 

Status 

Screen  shots:  Data  Logger  on  MD  PnP  platform 

1 

Q2  Rpt 

Completed 

Screen  shots:  Data  Logger  playback  for 
adverse  event  analysis,  narrative  text,  events 
on  timeline 

1 

Annual  Rpt 

Will  be  completed  by 
end  of  November 

Data  Logger  results  with  UDI 

1 

Annual  Rpt 

Will  be  completed  by 
end  of  November 

Beta  release  of  Scenario  Repository  to 
collaborators 

2 

Q2  Rpt 

Completed 

Launch  of  public  Scenario  Repository  website 

2 

Annual  Rpt 

Delayed  until  Option- 
Year  2 

Present  ICE  AX  at  conference  or  meeting 

3 

Q3  Rpt 

Completed 

App  framework  description 

3 

Annual  Rpt 

Completed 

Screen  shots:  prototype  connection  to  MGH 
test  ADT  system 

4 

Q3  Rpt 

See  below 

•  Screen  shots  of  Data  Logger  on  the  MD  PnP  platform  are  shown  in  Aim  1  of  this  report. 

•  Work  on  the  Data  Logger  playback  capability  and  other  remaining  functionality  will  be 
completed  by  the  end  of  Option-Year  1  (November  30). 

•  Work  on  the  Data  Logger  UDI  functionality  will  be  completed  by  the  end  of  Option-Year  1 
(November  30). 

•  Release  of  the  beta  version  of  the  Clinical  Scenario  Repository  to  collaborators  took 
place  in  December. 

•  We  are  delaying  any  public  launch  of  the  CSR™  until  we  can  first  resolve  governance 
issues;  anticipated  for  Option-Year  2. 

•  Present  ICE  AX  at  conference  or  meeting  -  Photos  from  our  demonstration  at  the 
HIMSS14  annual  conference  in  February  are  included  in  Aim  3  of  this  report. 

•  A  description  of  the  app  framework  -  We  set  up  OpenICE.info  to  support  developers  in 
using  our  framework  to  build  apps.  The  site  contains  documentation,  code,  and  a  live 
demo  of  streaming  device  data  from  the  MD  PnP  lab  in  Cambridge.  The  data  is  sent 
using  WebSockets,  a  technology  supported  by  all  modern  web  browsers,  and  which  is 
usable  in  many  programming  languages  including  C,  C++,  and  Java.  Our  OpenICE 
demo  code  is  written  in  JavaScript  and  runs  in  the  web  browser  in  order  to  make  it  as 
easy  as  possible  for  clinical  users,  who  may  not  be  trained  programmers,  to  use  the 
platform.  The  live  demo  is  viewable  at  www.openice.info 
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•  Screen  shots:  prototype  connection  to  MGH  test  ADT  system  -  as  described  in  Aim  4  of 
this  report,  impending  changes  in  the  MGH  EHR  and  related  systems  has  forced  the 
postponement  of  this  work  to  a  later  time,  and  we  have  instead  pursued  work  with 
OSEHRA  VistA. 

Key  Research  Accomplishments 

•  New  implementation  ICE  Data  Logger.  In  collaboration  with  NIST  on  the  next  Data 
Logger  implementation,  we  built  preliminary  data  logging  functionality  on  the  OMG  DDS 
(standards-based)  middleware  we  are  using  for  our  OpenICE  platform  development, 
using  our  ICE  Equipment  Interfaces,  and  are  successfully  logging  data.  With  NIST,  we 
are  researching  the  best  approach  to  long-term  storage  of  logged  data  and  performing 
experiments  to  compare  the  performance  of  MySQL  and  other  data  stores  for  recording 
and  searching  data.  This  allows  us  to  perform  end-to-end  testing  of  the  entire  OpenICE 
system  from  the  equipment  interface  through  to  the  Data  Logger  as  we  revise  our 
OpenICE  platform. 

•  Beta  version  Clinical  Scenario  Repository.  We  presented  a  beta  version  of  the 
Clinical  Scenario  Repository  at  the  STA  annual  meeting  and  a  meeting  of  the  Society  for 
Critical  Care  Medicine  in  January  2014,  where  valuable  feedback  was  gathered.  We 
have  successfully  deployed  the  CSR™  web  application  on  our  own  managed  servers, 
moving  away  from  the  Google  Application  Engine  that  was  used  in  the  prototype’s  early 
stages.  This  will  help  prepare  for  a  broader  MGH  pilot. 

•  SourceForge  Code-Sharing  Repository.  We  started  an  open-source  code-sharing 
environment  on  SourceForge  in  March  2013  where  our  project  code  is  available  for 
downloading  -  to  date,  we  have  recorded  hundreds  of  downloads  from  dozens  of 
countries. 

•  HIMSS14  Demonstration.  In  the  ONC  area  of  the  Interoperability  Showcase  at 
HIMSS14,  we  demonstrated  a  new  ICE  app,  “Real-Time  Blue  Button  for  Patients  and 
Families,”  that  streams  physiological  data  (including  waveforms)  from  medical  devices 
connected  at  our  lab  in  Cambridge,  MA,  as  well  as  data  from  medical  devices  connected 
locally.  For  this  demo  we  built  a  prototype  ICE  External  Interface  suitable  for  live 
streaming  data,  an  Android  app  to  display  the  data,  and  an  ICE  application  that 
packages  up  the  data  and  sends  it  to  the  phone  or  tablet.  We  were  able  to  share  the 
demo  with  the  new  National  Coordinator  for  Health  IT,  Dr.  Karen  DeSalvo,  and  to  Col. 
Dan  Krai  and  others  from  TATRC. 

•  SmartAmerica  Challenge.  The  Closed  Loop  Healthcare  team,  comprised  of  groups 
from  academia,  industry,  research  and  government,  was  formed  at  the  Presidential 
Innovation  Fellows’  SmartAmerica  Challenge  in  December  2013.  During  a  three-day 
meeting  and  “hackathon”  in  our  lab  in  March  2014,  we  made  progress  with  a  number  of 
collaborators  as  the  team  developed  a  prototype  to  be  demonstrated  at  the  White 
House-hosted  SmartAmerica  Expo  in  Washington,  DC  in  June.  We  moved  NIST  forward 
on  the  Data  Logger  work,  brought  together  vendors  of  DDS  middleware  to  demonstrate 
interoperability  between  their  implementations,  and  Closed  Loop  Healthcare 
collaborators  shared  integration  strategies  at  the  enterprise  level,  both  for  data 
integration  and  for  data  storage. 

In  addition  to  the  specific  achievements  above,  the  MD  PnP  program  has  continued  to  gain 
increasing  traction  through  our  collaborative  relationships.  The  web  of  connections  among 
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people  in  our  community  of  interest  continues  to  generate  new  connections  to  supportive 
individuals  in  government  agencies,  healthcare  institutions,  and  other  organizations  who  are 
helping  to  further  the  aims  of  the  program. 


Reportable  Outcomes 
150+  Meetings: 

•  August  2013  -  July  2014  -  weekly  teleconference  calls  of  the  Medical  Device 
Interoperability  Safety  (MDIS)  working  group  (successor  to  the  PRS,  the  Prototype 
Regulatory  Submission  working  group)  to  refine  the  Pre-IDE  submission  to  FDA 

•  August  2013  -  July  2014  -  31  MD  PnP  lab  demonstrations  for  device  manufacturers, 
standards  groups,  and  researchers 

•  August  201 3  -  October  2013-6  teleconference  calls  of  the  HIT  Policy  Committee’s 
FDASIA  Workgroup 

•  August  2013  -  July  2014  -  regular  teleconference  calls  of  the  MDIS  working  group  on 
AAMI/UL  2800  coordination,  followed  by  telcons  (weekly  starting  end  of  March  2014)  of 
the  Committee  working  on  the  AAMI  /  UL  2800  family  of  standards 

•  August  1  2013  -  FDA  Telcon  on  Mobile  Medical  Apps 

•  August  2  201 3  -  FCC  Consumer  Advisory  Committee  meeting,  Washington,  DC 

•  August  21-22  2013  -  MD  PnP  technology  demonstrations  for  federal  agencies  at  NIH, 
Rockville,  MD 

•  September  10  2013  -  Panel  on  Smart  Healthcare  Technologies  for  NSF  SBIR/STTR 
program,  Arlington,  VA 

•  September  12  2013  -  Meeting  of  the  DoD  JPC1  HIT  working  group,  Washington,  DC 

•  September  27  2013  -  Hosted  Open  Health  Tools  Board  meeting,  Cambridge,  MA 

•  November  2013  -  April  2014  -  5  telcons  for  the  FCC  Consumer  Advisory  Committee 
Healthcare  Working  Group 

•  December  4  201 3  -  DICOM  Working  Group  24  conference  call 

•  December  1 1  2013  -  FCC  mHealth  Summit,  Washington,  DC 

•  December  16  2013  -  FCC  Consumer  Advisory  Committee  Plenary  Meeting,  Washington, 
DC 

•  December  19  2013  -  AAMI  HTSI  Alarm  Steering  Committee  conference  call 

•  January  2014  -  June  2014  -  15  telcons  for  the  SmartAmerica  Closed  Loop  Healthcare 
group,  formed  at  the  December  2013  CPS  Testbed  Challenge  in  Washington,  DC 

•  February  6  2014  -  NSF  CPS  Workshop,  Washington,  DC 

•  February  1 1  2014  -  SmartAmerica  Challenge  Workshop  held  at  NIST,  Washington,  DC 

•  March  5  2014  -  VA  Time  Workshop,  Washington,  DC 

•  March  18-20  2014  -  SmartAmerica  Closed  Loop  Healthcare  team  “hackathon”  in  the 
MD  PnP  Interoperability  Lab,  Cambridge,  MA 

•  March  26  2014  -  Workshop  on  NSF  CPS  References  Architecture,  Washington,  DC 

•  March  28  2014  -  Meeting  of  the  FCC  Consumer  Advisory  Committee  Healthcare 
Working  Group,  Washington,  DC 

•  April  24-25  2014  -  Meetings  of  the  AAMI  Alarms  Coalition,  Washington,  DC 

•  April  2014-2  telcons  of  the  Committee  working  on  US  TAG  ISO  TC  121  on  Anesthetic 
and  Respiratory  Equipment  and  the  transition  from  ASTM  to  AAMI 

•  May  4-6  2014  -  Meetings  of  the  UL  Health  Council,  Chicago,  IL 

•  May  7  2014  -  Chaired  (via  WebEx)  AAMI/AR  Committee  meeting  on  US  TAG  and  ISO 
TC  121  standards  work 
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•  May  13-15  2014  -  Meetings  of  the  HIT  Policy  Committee’s  FDASIA  Workgroup, 
Washington,  DC 

•  May  29  -  June  3  2014  -  AAMI  Standards  Week  meetings,  Philadelphia,  PA 

•  June  10-11  2014  -SmartAmerica  Expo,  Washington,  DC 

•  June  16-20  2014  -  Dr.  Goldman  chaired  43rd  Plenary  Meeting  of  ISO/TC121  and 
Subgroups,  Inchon,  Republic  of  Korea 

•  July  21  2014  -  Meeting  with  The  Open  Group,  open  standards  and  global 
interoperability  organization 

•  July  25  2014  -  Meeting  of  the  FCC  Consumer  Advisory  Committee  Healthcare  Working 
Group,  Washington,  DC 


29  Presentations  on  Medical  Device  Interoperability  Topics: 

Dr.  Goldman  delivered  invited  presentations  on  topics  related  to  medical  device  interoperability 
for  improving  patient  safety  and  healthcare  efficiency  to  the  following  groups  during  the  past 
year: 


•  September  16  2013  Keynote,  “Integrity  of  Medical  Device  Interoperability”  at  AHIMA 
Health  Information  Integrity  Summit,  Alexandria,  VA 

•  September  17-18  2013  Lecture  and  panel,  “Advanced  Medical  Technology  Training  and 
the  APSF  Recommendations:  Perspectives  from  my  Vantage  Point”  at  meeting  of  the 
Anesthesia  Patient  Safety  Foundation,  Phoenix,  AZ 

•  September  24-25  2014  MD  PnP  Lab  Open  House  with  technology  demonstrations 

•  October  12-15  2013  Research  updates  at  annual  ASA  meeting,  to  Scientific  & 
Educational  Exhibits  Committee;  Committee  on  Technology;  Equipment,  Monitoring  & 
Engineering  Technology  Committee;  Equipment  &  Facilities  Committee;  and  Electronic 
Media  &  Information  Technology  Committee,  San  Francisco,  CA 

•  October  17  2013  Lecture,  “CPS  Test  Beds:  Medical  Devices”  at  CPS  Pis  meeting, 
Washington,  DC 

•  November  18-20  2013  Plenary,  “The  SHARP  Program  and  the  Next  Generation  of 
Health  Information  Technology”  at  the  SHARP  ONC  plenary  at  AMIA  Annual 
Symposium,  Washington,  DC 

•  November  21  2013  Keynote  “Introduction  to  an  Open-Source  Integrated  Clinical 
(ICE)Environment  Platform,”  Keynote  Panel  “The  Regulatory  Future  for  Health  IT,  Mobile 
Applications,  and  Interoperability”  and  Plenary  Panel  “Interoperability  Standards:  How 
Far  Can  They  Take  Us?”  at  Medical  Device  Connectivity  Conference,  Herndon,  VA 

•  December  12  2013  Presentation  of  Virtual  Hospital  CPS  Testbed  Proposal  at  White 
House  SmartAmerica  CPS  Testbed  Challenge,  Washington,  DC 

•  January  10  2014  Panel,  “Interoperability:  A  Cornerstone  of  Systems  Integration”  at 
Society  of  Critical  Care  Medicine  Annual  Congress,  San  Francisco,  CA 

•  January  21-22  2014  Chaired  Meetings  for  US  TAG  ISO  TC  121  on  Anesthetic  and 
Respiratory  Equipment  to  lead  the  transition  of  the  US  TAG  from  ASTM  to  AAMI 

•  February  24-26  2014  Technology  Demonstration,  “Real-Time  Blue  Button™  for  Patients 
&  Families”  in  the  ONC/FHA  area  of  the  HIMSS’14  Interoperability  Showcase,  Orlando, 
FL 

•  February  26  2014  Lecture,  “Safe  Interoperability:  What  are  the  Challenges?"  in  the 
HIMSS’14  Interoperability  Showcase  Theater,  Orlando,  FL 

•  April  1  2014  Lecture,  “Enabling  Innovation  Through  Medical  Device  Interoperability:  from 
architecture  to  analytics”  at  the  Children’s  Hospital  of  Philadelphia 
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•  April  10  2014  Lecture,  “Towards  Better  Critical  Care:  From  data  to  information  to 
decision  to  action”  at  Society  of  Critical  Care  Medicine  Research  Summit,  Emory 
Conference  Center,  Atlanta,  GA 

•  May  14  2014  Panels,  “Conformity  assessment  -  Role  in  assuring  safety  and  innovation.” 
and  “Standards  and  Interoperability”  at  NIST/FDASIA  Public  Workshop:  Proposed  Risk- 
Based  Regulatory  Framework  and  Strategy  for  Health  Information  Technology, 
Washington,  DC 

•  May  15  2014  Panel,  “Health  IT  Safety  Center”  at  NIST/FDASIA  Public  Workshop: 
Proposed  Risk-Based  Regulatory  Framework  and  Strategy  for  Health  Information 
Technology,  Washington,  DC 

•  June  10-1 1  2014  Lecture  and  technology  demonstrations,  “Closed-Loop  Healthcare: 
From  Home  to  Hospital  to  Home”  at  White  House  SmartAmerica  Expo,  Washington,  DC 

•  July  9  2014  Congressional  briefing  on  Medical  Device  Inoperability  and  Safe  Medical 
Integration,  Washington,  DC 

•  July  22  2014  MD  PnP  Lab  Open  House  with  technology  demonstrations 

5  Presentations  on  behalf  of  the  PI: 

•  December  6  2013  Technology  demonstration  at  FCC  mHealth  Innovation  Expo  by  Dave 
Arney  and  Jeff  Plourde,  Washington,  DC 

•  April  2  2014  Poster  presentation  on  “Web-Based  Clinical  Scenario  Repository  to 
Improve  Patient  Safety”  at  Mass  General  Hospital  Scientific  Advisory  Council  poster 
sessions  by  Diego  Alonso 

•  April  14  2014  Lecture  on  paper  “Design  Pillars  for  Medical  Cyber-Physical  System 
Middleware"  by  Dave  Arney  and  Jeff  Plourde  at  Medical  CPS  Workshop,  Berlin, 
Germany 

•  April  14  2014  Poster  presentation  on  "Potential  Advantages  of  Applying  Assurance  Case 
Modeling  to  Requirements  Engineering  for  Interoperable  Medical  Device  Systems”  by 
Dave  Arney  and  Jeff  Plourde  at  Medical  CPS  Workshop,  Berlin,  Germany 

•  April  16  2014  Poster  and  Work  in  Progress  talk  on  "OpenICE:  An  Open,  Interoperable 
Platform  for  Medical  Cyber-Physical  Systems”  at  the  International  Conference  on  Cyber- 
Physical  Systems  (ICCPS)  by  Dave  Arney  and  Jeff  Plourde,  Berlin,  Germany 

Web  Site: 

•  www.mdpnp.org  is  maintained  as  a  major  communication  vehicle  for  the  program  and 
had  a  major  redesign  this  past  year.  The  website  provides  access  to  the  ICE  standard, 
MD  FIRE  contracting  language,  publications,  posters,  links  to  streaming  video  of  talks 
from  plenary  meetings  and  from  the  FDA  Workshop,  and  downloads  of  sharable 
documents  and  code  via  our  SourceForge  public  project  at 

http://www.mdpnp.org/Download  Files.html.  On  the  website  we  now  advertise  General 
Membership  in  the  MD  PnP  community,  offering  updates  in  our  occasional  eNewsletter, 
access  to  documentation,  software,  and  educational  materials,  and  an  invitation  to  the 
RTI  Infrastructure  Community  for  Implementation  of  DDS.  We  currently  have  194 
members,  and  the  website  receives  about  1 ,000  visits  per  week. 
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Manuscripts/Publications: 

•  Pajic  M,  Mangharam  R,  Sokolsky  O,  Arney  D,  Goldman  JM,  Lee  I.  Model-Driven  Safety 
Analysis  of  Closed-Loop  Medical  Systems.  IEEE  Transactions  on  Industrial  Informatics 
2014;  1:3-16. 

•  Arney  D,  Plourde  J,  Schrenker  R,  Mattegunta  P,  Whitehead  SF,  Goldman  JM.  Design 
Pillars  for  Medical  Cyber-Physical  System  Middleware.  In:  Turau  V,  Kwiatkowska  M, 
Mangharam  R,  Weyer  C,  editors.  Proceedings  of  the  5th  Workshop  on  Medical  Cyber- 
Physical  Systems;  2014  April  14;  Berlin,  Germany.  Dagstuhl:  Schloss  Dagstuhl;  2014. 
vol.  36  p.  124-132. 

•  Food  and  Drug  Administration  Safety  Innovation  Act  (FDASIA)  Workgroup.  FDASIA 
Health  IT  Report:  Proposed  Strategy  and  Recommendations  for  a  Risk-Based 
Framework.  Published  April  2014.  [Contributions  by  Dr.  Goldman  as  part  of  Workgroup] 
Available  at 

http://www.fda.qov/downloads/AboutFDA/CentersOffices/OfficeofMedicalProductsandTo 

bacco/CDRH/CDRHReports/UCM391 521  .pdf 

•  Goldman  JM.  The  Challenge  of  Acquiring  Accurate,  Complete,  Near-Patient  Clinical 
Data  for  Data  Science  Analysis.  NIST  Data  Science  Symposium  Proceedings  March  4-5 
2014,  Gaithersburg,  MD;  2014.  p.  43-44. 

Funding  Applications  Facilitated  by  this  BAA  to  Date  (total  costs  shown): 

•  NSF  14-1  Solicitation  under  CNS  -  CYBER-PHYSICAL  SYSTEMS  (CPS) 

3  Year  award  for  $1 ,500,000  Total 

Proposal  for  an  MCPS  Testbed  distributed  between  Massachusetts  General  Hospital 
and  University  of  Pennsylvania,  providing  a  physically  and  remotely  accessible  resource 
that  allows  researchers  to  access  streaming  of  medical  device  data  and  software 
simulated  patient  data,  use  these  data  as  inputs  to  a  variety  of  algorithms,  control 
medical  devices  based  on  the  outputs  of  these  algorithms,  and  evaluate  the  effects  of 
these  control  activities  using  patient  models. 


Conclusions 

This  award  is  supporting  the  development  of  core  capabilities  for  medical  device  interoperability 
for  the  healthcare  technology  ecosystem  to  enable  the  next  generation  of  safe  and  intelligent 
medical  device  and  HIT  systems. 

The  Clinical  Scenario  Repository  (CSR)  is  enabling  the  voice  of  the  customer  to  be  captured  to 
guide  the  development  of  standards  and  technologies.  It  differs  from  conventional  “safety 
reports”  that  are  based  on  mandatory  reporting  of  adverse  events.  The  CSR  is  intended  to 
contain  clinical  scenarios  or  “good  ideas  for  interoperability”  that  if  implemented,  could  improve 
safety,  improve  workflow,  and  facilitate  innovation.  These  “Good  Ideas”  can  serve  as  design 
inputs  for  a  system  of  standards  and  technology  development,  and  help  insure  that 
interoperability  solutions  are  clinically  driven.  It  could  become  a  core  means  by  which  the  clinical 
user  community  can  clarify  expectations  of  new  technologies  and  integrated  medical  device-HIT 
system  capabilities  for  use  by  developers,  regulators,  researchers,  and  equipment  procurers. 

Open  platforms,  including  reference  implementations  of  standards  and  architectures,  are 
needed  for  the  adoption  of  interoperability.  These  must  be  fully  and  freely  available  to  the 
community  of  hospitals,  manufacturers,  standards  developers,  computer  science  and 
engineering  students,  app  developers,  regulators,  and  everyone  else  that  is  eager  to  work 
together  to  mature  the  healthcare  technology  ecosystem  to  enable  the  next  generation  of  safe 


August  2014 


21 


and  intelligent  medical  device  and  HIT  systems.  The  ICE  Data  Logger  is  an  essential 
component  of  the  ICE  platform  and  the  collaboration  with  NIST  and  updated  standards-based 
technology  approach  (OMG  DDS)  are  important  steps  towards  adoption.  As  detailed  in  the 
report,  we  have  been  broadly  sharing  software  and  implementation  instructions  to  support  and 
grow  the  community. 


References 

1.  Goldman  JM,  Jackson  JL,  Whitehead  SF,  Rausch  TL,  Weininger  S,  “The  Medical  Device 
‘Plug-and-Play’  (MD  PnP)  Interoperability  Program,”  part  of  Schrenker  RA,  “Software 
Engineering  for  Future  Healthcare  and  Clinical  Systems,”  IEEE  Computer,  April  2006. 

2.  Goldman  JM,  “Medical  Device  Connectivity  for  Improving  Safety  and  Efficiency,” 
American  Society  of  Anesthesiology  Newsletter  70\5,  May  2006. 

3.  Goldman  JM,  “Patient-Centric  Networked  Medical  Device  Interoperability,”  part  of 
Dagalakis  NG,  “Report  on  the  Results  of  the  NIST  Medical  Devices  Metrology  and 
Standards  Needs  Workshop,”  November  2006. 
http://www.nist.qov/el/isd/upload/USMS  Med  Dev  Needs.pdf 

4.  Goldman  JM,  Whitehead  S,  Weininger  S,  “Eliciting  Clinical  Requirements  for  the  Medical 
Device  Plug-and-Play  (MD  PnP)  Interoperability  Program,”  Anesthesia  &  Analgesia 
2006;102:S1-54. 

5.  Cooney  E,  “Getting  medical  devices  to  talk  to  each  other,”  in  “White  Coat  Notes,”  the 
Boston  Globe  online,  June  2007. 

http://www.boston.com/vourlife/health/bloq/2007/06/qettinq  medical  1  .html 

6.  Carr  S,  “Plug  and  Play  for  Patient  Safety,”  Patient  Safety  &  Quality  Healthcare,  July-Aug 
2007.  http://www.psqh.com/iulauq07/editor.html 

7.  Lesh  K,  Weininger  S,  Goldman  JM,  Wilson  B,  Himes  G,  “Medical  Device  Interoperability 
-  Assessing  the  Environment,”  Proceedings  of  the  Joint  Workshop  on  High-Confidence 
Medical  Devices,  Software,  and  Systems  and  Medical  Device  Plug-and-Play 
Interoperability  (HCMDSS  /  MD  PnP  2007),  Cambridge,  MA,  June  25-27,  2007,  pp.  3-12. 
IEEE  Computer  Society  Press,  2008. 

8.  Rausch  T,  Jackson  JL,  “Using  Clinical  Workflows  to  Improve  Medical  Device/System 
Development,”  Proceedings  of  the  Joint  Workshop  on  High-Confidence  Medical  Devices, 
Software,  and  Systems  and  Medical  Device  Plug-and-Play  Interoperability  (HCMDSS  / 
MD  PnP  2007),  Cambridge,  MA,  June  25-27,  2007,  pp.  133-134.  IEEE  Computer 
Society  Press,  2008. 

9.  Schrenker  RA,  “Ensuring  Sufficient  Breadth  in  Use  Case  Development:  How  Should 
Non-Functional  Requirements  Be  Elicited  and  Represented?”  Proceedings  of  the  Joint 
Workshop  on  High-Confidence  Medical  Devices,  Software,  and  Systems  and  Medical 
Device  Plug-and-Play  Interoperability  (HCMDSS  /  MD  PnP  2007),  Cambridge,  MA,  June 
25-27,  2007,  pp.  135-136.  IEEE  Computer  Society  Press,  2008. 

10.  Cortes  P-A,  Krishnan  SM,  Lee  I,  Goldman  JM,  “Improving  the  Safety  of  Patient- 
Controlled  Analgesia  Infusions  with  Safety  Interlocks,”  Proceedings  of  the  Joint 
Workshop  on  High-Confidence  Medical  Devices,  Software,  and  Systems  and  Medical 
Device  Plug-and-Play  Interoperability  (HCMDSS  /  MD  PnP  2007),  Cambridge,  MA,  June 
25-27,  2007,  pp.  149-150.  IEEE  Computer  Society  Press,  2008. 

11.  Arney  D,  Goldman  JM,  Lee  I,  Llukacej  E,  Whitehead  S,  “Use  Case  Demonstration:  X- 
Ray/Ventilator,”  Proceedings  of  the  Joint  Workshop  on  High-Confidence  Medical 
Devices,  Software,  and  Systems  and  Medical  Device  Plug-and-Play  Interoperability 
(HCMDSS /MD  PnP  2007),  Cambridge,  MA,  June  25-27,  2007,  p.  160.  IEEE  Computer 
Society  Press,  2008. 


August  2014 


22 


12.  McBride  R,  “Doc:  Plug-and-play  med  devices  could  save  lives,”  Mass  High  Tech  26:4, 
p.  7,  Jan  18-24,  2008. 

http://www.biziournals.com/masshiqhtech/stories/2008/01/21/storv1 1.html?ana 

13.  Whitehead  SF,  Goldman  JM,  “Getting  Connected  for  Patient  Safety,”  Patient  Safety  & 
Quality  Healthcare  5:1 ,  Jan-Feb  2008. 

14.  Chiao  JC,  Goldman  JM,  Heck  DA,  Kazanzides  P,  Peine  WJ,  Stiehl  JB,  Yen  D,  Dagalakis 
NG,  “Metrology  and  Standards  Needs  for  Some  Categories  of  Medical  Devices,”  J.  Res. 
Natl.  Inst.  Stand.  Technol.  113,  121-129,  2008. 

15.  Wallroth  C,  Goldman  J,  Manigel  J,  Osborn  D,  Roellike  T,  Weininger  S,  Westenskow  D, 
“Development  of  a  Standard  for  Physiologic  Closed  Loop  Controllers  in  Medical 
Devices,”  Anesth  Analg  106,  S-21, 2008. 

16.  Wallroth  C,  Goldman  J,  Manigel  J,  Osborn  D,  Weinstein  W,  Weininger  S,  Westenskow 
D,  “Development  of  a  Standard  for  the  Interoperability  of  Medical  Devices,”  Anesth  Analg 
106,  S-23,  2008. 

17.  Coop  CE,  Mosher  R,  Kun  L,  Geiling  J,  Grigg  E,  Long  S,  Macedonia  C,  Merrell  RC, 

Satava  R,  Rosen  JM,  “Future  Delivery  of  Health  Care:  Cyber  Care,”  IEEE  Engineering  in 
Medicine  &  Biology  27:6,  29-38,  Nov/Dec  2008. 

18.  Agres  T,  “Model  Contract  Gives  Momentum  to  Interoperability  Movement,” 
Anesthesiology  News  34:12,  December  2008. 

19.  Johnson  C,  “Medical  devices  lag  in  iPod  age,”  The  Boston  Globe,  December  29  2008. 

20.  Whitehead  SF,  Goldman  JM,  “Hospitals  Issue  Call  for  Action  on  Medical  Device 
Interoperability,”  Patient  Safety  &  Quality  Healthcare  6:1 ,  Jan-Feb  2009. 

21 .  Arney  D,  Goldman  JM,  Whitehead  SF,  Lee  I,  "Synchronizing  an  X-ray  and  Anesthesia 
Machine  Ventilator:  A  Medical  Device  Interoperability  Case  Study",  Proceedings  of 
Bio  Devices  2009. 

22.  Anand  M,  Fischmeister  S,  Lee  I,  “Resource  Scopes:  Toward  Language  Support  for 
Compositional  Determinism,”  Proc.  of  the  12th  IEEE  International  Symposium  on 
Object/component/service-oriented  Real-time  Distributed  Computing  (ISORC),  Tokyo, 
Japan,  Mar  2009. 

23.  Fischmeister  S,  Lam  P,  “On  Time-Aware  Instrumentation,”  Proc.  of  the  15th  IEEE  Real- 
Time  and  Embedded  Technology  and  Applications  Symposium  (RTAS),  San  Francisco, 
April  2009. 

24.  Whitehead  SF,  Goldman  JM,  “Connectivity  to  Improve  Patient  Safety:  Making  Medical 
Device  ‘Plug-and-Play’  Interoperability  a  Reality,”  Patient  Safety  &  Quality  Healthcare 
7:1, 26-30,  Jan-Feb  2010. 

25.  Kowalczyk  L,  “MGH  death  spurs  review  of  patient  monitors,”  The  Boston  Globe, 

February  21  2010. 

26.  Kowalczyk  L,  ‘“Alarm  fatigue’  linked  to  patient’s  death,”  The  Boston  Globe,  April  3  2010. 

27.  Arney  D,  Pajic  M,  Goldman  JM,  Lee  I,  Mangharam  R,  Sokolsky  O,  “Toward  Patient 
Safety  in  Closed-Loop  Medical  Device  Systems,”  In:  Proceedings  of  International 
Conference  on  Cyber  Physical  Systems,  April  2010. 

28.  Saver  C,  “Integrating  Devices  for  Patient  Safety,”  OR  Manager  26:6,  21-24,  June  2010. 

29.  Fischmeister  S,  Azim  A,  “Design  Choices  for  High-Confidence  Distributed  Real-time 
Software,”  Proc.  of  the  International  Symposium  on  Leveraging  Applications  of  Formal 
Methods,  Verification  and  Validation  (ISoLA),  Heraclion,  Crete,  2010. 

30.  Goldman  JM,  Schrenker  R,  Melendez  L,  Hampton  R,  Driscoll  W.  Implications  of  the  New 
FDA  Medical  Device  Data  System  (MDDS)  Regulation  for  Automated  Clinical 
Documentation.  Proceedings  of  American  Society  of  Anesthesiologists:  Equipment, 
Monitoring  and  Technology.  October  201 1 . 


August  2014 


23 


31.  Arney  D,  Goldman  JM,  Bhargav-Spantzel  A,  Basu  A,  Taborn  M,  Pappas  G,  Robkin  M. 
Simulation  of  Medical  Device  Network  Performance  and  Requirements  for  an  Integrated 
Clinical  Environment.  Biomed  Instrum  Technol  2012  Jul-Aug;46(4):308-15. 
http://mdpnp.org/publications  UN9U.html 


Relevant  documents  are  linked  to  from  the  text  of  the  report. 


August  2014 


24 


